…e annotation

bee450b (ci-operator: expose ephemeral cluster versions based on
parents, 2020-08-11, openshift#1098) taught assembleReleaseStep to consume the
release.openshift.io/config annotation on an ImageStream to find a
version prefix that actually reflects the 4.y release branch (instead
of using 0.0.1-0 as the prefix).  Those annotations are set on the
app.ci ImageStreams, for example:

  $ oc whoami -c
  default/api-ci-l2s4-p1-openshiftapps-com:6443/wking
  $ oc -n ocp get -o json imagestream 4.13 | jq -r '.metadata.annotations["release.openshift.io/config"] | fromjson | .name'
  4.13.0-0.ci

But they are not set in ImageStreams contained within release images:

  $ oc adm release info -o json registry.ci.openshift.org/ocp/release:4.13.0-0.ci-2023-03-29-224346 | jq '.references | {kind, metadata}'
  {
    "kind": "ImageStream",
    "metadata": {
      "name": "4.13.0-0.ci-2023-03-29-224346",
      "creationTimestamp": "2023-03-29T22:52:54Z",
      "annotations": {
        "release.openshift.io/from-image-stream": "ocp/4.13-2023-03-29-224346"
      }
    }
  }

With this commit, I'm taking the name out of the imported release
ImageStream and trying to parse it as a Semantic Version.  If it
parses, I'm constructing a release.openshift.io/config annotation to
set just the 'name' property to the MAJOR.MINOR.SPEC from that parsed
name.  This should allow cluster-bot runs like:

  launch 4.13.0-0.ci,openshift/cluster-version-operator#918,openshift/hypershift#2318 hypershift-hosted

to build releases named 4.13.0-0-... instead of their current
0.0.1-0-...:

  $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880/artifacts/release/artifacts/release-payload-latest/image-references | jq -r .metadata.name
  0.0.1-0.test-2023-03-30-043404-ci-ln-h9dwcbk-latest

which is failing to run with [1]:

  Release image is not valid: {
    "lastTransitionTime": "2023-03-30T04:36:29Z",
    "message": "releases before 4.8 are not supported",
    "observedGeneration": 3,
    "reason": "InvalidImage",
    "status": "False",
    "type": "ValidReleaseImage"
  }

[1]: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880#1:build-log.txt%3A203-210

…e annotation

bee450b (ci-operator: expose ephemeral cluster versions based on
parents, 2020-08-11, openshift#1098) taught assembleReleaseStep to consume the
release.openshift.io/config annotation on an ImageStream to find a
version prefix that actually reflects the 4.y release branch (instead
of using 0.0.1-0 as the prefix).  Those annotations are set on the
app.ci ImageStreams, for example:

  $ oc whoami -c
  default/api-ci-l2s4-p1-openshiftapps-com:6443/wking
  $ oc -n ocp get -o json imagestream 4.13 | jq -r '.metadata.annotations["release.openshift.io/config"] | fromjson | .name'
  4.13.0-0.ci

But they are not set in ImageStreams contained within release images:

  $ oc adm release info -o json registry.ci.openshift.org/ocp/release:4.13.0-0.ci-2023-03-29-224346 | jq '.references | {kind, metadata}'
  {
    "kind": "ImageStream",
    "metadata": {
      "name": "4.13.0-0.ci-2023-03-29-224346",
      "creationTimestamp": "2023-03-29T22:52:54Z",
      "annotations": {
        "release.openshift.io/from-image-stream": "ocp/4.13-2023-03-29-224346"
      }
    }
  }

With this commit, I'm taking the name out of the imported release
ImageStream and trying to parse it as a Semantic Version.  If it
parses, I'm constructing a release.openshift.io/config annotation to
set just the 'name' property to the MAJOR.MINOR.PATCH from that parsed
name.  This should allow cluster-bot runs like:

  launch 4.13.0-0.ci,openshift/cluster-version-operator#918,openshift/hypershift#2318 hypershift-hosted

to build releases named 4.13.0-0-... instead of their current
0.0.1-0-...:

  $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880/artifacts/release/artifacts/release-payload-latest/image-references | jq -r .metadata.name
  0.0.1-0.test-2023-03-30-043404-ci-ln-h9dwcbk-latest

which is failing to run with [1]:

  Release image is not valid: {
    "lastTransitionTime": "2023-03-30T04:36:29Z",
    "message": "releases before 4.8 are not supported",
    "observedGeneration": 3,
    "reason": "InvalidImage",
    "status": "False",
    "type": "ValidReleaseImage"
  }

[1]: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880#1:build-log.txt%3A203-210

…e annotation

bee450b (ci-operator: expose ephemeral cluster versions based on
parents, 2020-08-11, openshift#1098) taught assembleReleaseStep to consume the
release.openshift.io/config annotation on an ImageStream to find a
version prefix that actually reflects the 4.y release branch (instead
of using 0.0.1-0 as the prefix).  Those annotations are set on the
app.ci ImageStreams, for example:

  $ oc whoami -c
  default/api-ci-l2s4-p1-openshiftapps-com:6443/wking
  $ oc -n ocp get -o json imagestream 4.13 | jq -r '.metadata.annotations["release.openshift.io/config"] | fromjson | .name'
  4.13.0-0.ci

But they are not set in ImageStreams contained within release images:

  $ oc adm release info -o json registry.ci.openshift.org/ocp/release:4.13.0-0.ci-2023-03-29-224346 | jq '.references | {kind, metadata}'
  {
    "kind": "ImageStream",
    "metadata": {
      "name": "4.13.0-0.ci-2023-03-29-224346",
      "creationTimestamp": "2023-03-29T22:52:54Z",
      "annotations": {
        "release.openshift.io/from-image-stream": "ocp/4.13-2023-03-29-224346"
      }
    }
  }

With this commit, I'm taking the name out of the imported release
ImageStream and trying to parse it as a Semantic Version.  If it
parses, I'm constructing a release.openshift.io/config annotation to
set just the 'name' property to the MAJOR.MINOR.PATCH from that parsed
name.  This should allow cluster-bot runs like:

  launch 4.13.0-0.ci,openshift/cluster-version-operator#918,openshift/hypershift#2318 hypershift-hosted

to build releases named 4.13.0-0-... instead of their current
0.0.1-0-...:

  $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880/artifacts/release/artifacts/release-payload-latest/image-references | jq -r .metadata.name
  0.0.1-0.test-2023-03-30-043404-ci-ln-h9dwcbk-latest

which is failing to run with [1]:

  Release image is not valid: {
    "lastTransitionTime": "2023-03-30T04:36:29Z",
    "message": "releases before 4.8 are not supported",
    "observedGeneration": 3,
    "reason": "InvalidImage",
    "status": "False",
    "type": "ValidReleaseImage"
  }

[1]: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880#1:build-log.txt%3A203-210

…ious, not rollback SemVer

In 9ac845f (pkg/payload/precondition/clusterversion/rollback: New
precondition, 2023-03-25, openshift#918), we grew a new precondition that
parsed the current and target releases as semantic versions and
rejected rollbacks.  Admins could use 'force: true' to push through
those (and other) guards, e.g. for testing purposes.

However, we still lacked guards around SemVer increases, like 4.14.z
hopping straight to 4.16.  In most cases, customers will be using an
OpenShift Update Service with a channel, and getting recommended
updates they can use with 'oc adm upgrade --to ...' or the in-cluster
web-console.  But some clusters are not using update services.

* ARO clusters are not subscribed to a channel by default and need to
  opt in [1].
* Some disconnected/restricted-network clusters currently use
  --to-image updates, although I personally think they would be safer
  running a local update services [2].

With this commit, I'm stiffening the previous guard to consume the
previous-version metadata that's baked into release images [3] and
consumed by Cincinnati when creating the update service responses [4].
This isn't as helpful as using an actual update service, because it
will not include information about update risks we discover after
building the release [5].  But it's still strictly stronger than the
outgoing rollback-specific guard, and we haven't had to extend that
previous-release list since the 4.1 release candidates [6].

[1]: https://learn.microsoft.com/en-us/azure/openshift/howto-upgrade#check-for-azure-red-hat-openshift-cluster-upgrades
[2]: https://issues.redhat.com/browse/OTA-821
[3]: https://github.com/openshift/oc/blob/795bf1a6260847ecfc612da2ab11ea2d6e07da16/pkg/cli/admin/release/new.go#L135
[4]: https://github.com/openshift/cincinnati/blob/d77203d472ed5a7e00112c4d8265ba20f5034824/cincinnati/src/plugins/internal/graph_builder/release_scrape_dockerv2/registry/mod.rs#L419
[5]: https://github.com/openshift/cincinnati-graph-data#block-edges
[6]: https://github.com/openshift/cincinnati-graph-data/blob/c09842556a9c5d3920f9f2d004e24b6fb2f3a2de/raw/metadata.json

…nor-version updates

The previous logic blocked both minor-version increases and
minor-version decreases.  The new logic allows minor-version decreases
and patch updates (where the minor version doesn't change), unless
overrides are in effect.

Minor version decreases will still be blocked by 9ac845f
(pkg/payload/precondition/clusterversion/rollback: New precondition,
2023-03-25, openshift#918), which comes with a more appropriate message.